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A description of a compiler-assembler program named PROCESS III 
is given. This program is used to translate No. 1 ESS symbolic source 
programs to No. 1 ESS binary object programs. Included is a discussion 
of the PROCESS language, the Compool and macro facilities of the com- 
piler, and some requirements that motivated its design. 

I. INTRODUCTION 

No. 1 ESS is a stored -program control telephone switching system. 1 ■ 2 - 3 
The program consists of more than 100,000 instructions, each 44 bits in 
length, made up of 37 information bits and 7 check bits. To write such 
a program in binary (or octal) machine language is clearly impractical. 
To efficiently produce such large programs, modern techniques include 
the use of mnemonics or a symbolic language by the programmer. We 
say the programmer writes a source program in some kind of symbolic 
language, whereas the central control 2 executes an object program in its 
machine (binary) language. 

This article mainly describes the vehicle that translates No. 1 ESS 
source programs to No. 1 ESS object programs. Certain other items 
explain the progress of a No. 1 ESS program from inception as a source 
program to its final state as an object program. 

The vehicle developed for translating from No. 1 ESS source pro- 
grams to No. 1 ESS object programs is itself a program; this program, 
named PROCESS III,* is executed on the IBM 7094 general-purpose 
computer. In keeping with the current usage for the words "compiler" 
and "assembler," PROCESS III is said to be a "compiler-assembler," 
since it performs both functions, as will be described. Consequently, in 
this article the words "compiler" and "assembler" are used interchange- 
ably unless otherwise noted. 

* PROCESS is an acronym for PROgram to Compile ESS programs. 
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1.1 Background 

A compiler should come early in the development of a stored pro- 
gram system. The sooner one can translate to the object program, the 
sooner interpretive simulation may be undertaken; in turn, this means 
one may begin to feel confident sooner about such things as adequacy of 
order structure, and construction and size of the object program. 
PROCESS III was started early; although there were some definite ideas 
initially as to what some of its requirements would be, it was necessary 
to build a flexible structure to accommodate the many new require- 
ments that would arise as the development of the No. 1 ESS program 
progressed. 

Early in the development of No. 1 ESS, it was recognized that the 
object program would be large, and that it would be written, compiled, 
and tested in small sections of 1000 to 5000 instructions. Also known was 
the desirability of not having to disturb all parts of this large program 
in the semipermanent twistor memory when small sections were being 
tested and recompiled. Yet the sections had to communicate with each 
other and transfer control to each other. These considerations led to one 
basic design criterion for PROCESS III: while still insuring that com- 
munication and control among sections remain intact, it must be possi- 
ble to recompile and reinsert sections of the total object program with- 
out disturbing the whole. 

A more fundamental design criterion for the compiler arose from a 
lack of knowledge of the precise nature of the source program. It was 
known, of course, that the program was to do data processing in con- 
nection with telephone calls. Such actions are difficult to describe com- 
pletely in a simple or mathematical or uniform way. That is to say, 
there did not exist a "telephone language" that could be used to de- 
scribe completely the telephone data processing functions. However, 
it was known that some telephone functions are amenable to simple, 
mathematical, uniform description ; furthermore, as learning took place, 
it was hoped that the balance of the telephone functions could in time 
be described in a straightforward maimer. Thus, a fundamental design 
criterion for PROCESS III became flexibility: not only must the com- 
piler be able to handle known straightforward descriptions of telephone 
functions, but it must also be capable of being used to construct, ac- 
cept, and retain new descriptions of telephone functions. 

The requirements of independent compilation, integrity of communi- 
cation among sections of object programs, and flexibility have been 
met by PROCESS III because it: 

(1) normally produces relocatable object programs, 
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(2) has a communications pool (Compool) facility, and 

(3) has a powerful macro facility. 

A relocatable object program has each of its instructions assigned an 
address relative to zero, the address of its first instruction. The address 
field of each No. 1 ESS instruction in a given program section P may 
in turn refer to one of four kinds of numbers: 

(a) constants; these are said to be absolute numbers, since they will 
not be altered by subsequent processing; 

(b) a local program point, in which case the number is a relocatable 
address within the range of the object program instruction addresses 
of P; 

(c) a global program point, in which case the number is a pseudo-ad- 
dress that refers to a program other than P and therefore cannot be 
assigned explicity at the time P is compiled; and 

(d) fixed call store or program store locations; these numbers are 
absolute addresses outside the program P but within the range of the 
two memories. 

The total No. 1 ESS object program consists of many relocatable 
sections like P. Each section contains various numbers, as described. 
An immediate need for proper execution of the total object program by 
central control is a loading scheme for inserting this program into the 
twistor program store. The scheme is implemented by another IBM 
7094 program called a "loader." The loader accepts as inputs many 
object programs generated by PROCESS III and produces as output a 
single unified (linked) object program containing only absolute ad- 
dresses. Thus, having determined where sections of the object program 
will reside in the twistor store, the relocatable program points of (b) 
and the pseudo-addresses of (c) are changed by the loader to absolute 
addresses. The absolute numbers of (a) and (d) are not altered. The 
loader also has the ability to accept a more current version of a section 
(or sections) of the object program without disturbing the remaining 
sections. This means that fewer twistor cards need to be remagnetized 
during the checkout and debugging phases. Finally, the loader will 
generate and prefix 7 check bits to each 37-bit instruction. Since the 
Hamming code for these bits is a function of the 37 information bits 
and the absolute address at which the 37 bits reside in the twistor store, 
they cannot be generated prior to load time. 

The Compool facility of PROCESS III enables one to refer conven- 
iently to addresses of type (d). A major consideration in the design of 
the total object program is the temporary (call store) memory con- 
figuration. Temporary memory must be assigned to the call registers, 



2460 THE BELL SYSTEM TECHNICAL JOURNAL, SEPTEMBER 1964 

the network map, various queues, and so on. 3,4 Since there are many 
programmers involved in constructing the large No. 1 ESS object pro- 
gram, it is efficient to centralize the assignment of temporary memory. 
The Compool of PROCESS III provides this centralization. Having 
once defined call store areas in the Compool, the many individual pro- 
grammers need not concern themselves about such areas except to refer 
to them as necessary. In then programs, reference to these areas must 
be made symbolically, but there is no need for individual definition of 
such areas; the communications problem among programmers using 
the same call store areas is thereby substantially reduced by the Com- 
pool facility. 

The Compool, therefore, is a collection of symbols that are assigned 
call store addresses; these symbols correspond to areas set aside in 
memory in a particular configuration for the purpose of doing telephone 
data processing. Of course, the configuration may change as the de- 
velopment of the object program progresses. In this case, PROCESS 
III is used to update the Compool, and the new configuration is used in 
compiling all source programs thereafter. It may be necessary for 
source programs to be recompiled, depending on the change in call 
store configuration. This too is partially automated: when a Compool 
run (i.e., a change in call store configuration) is made, PROCESS III 
refers to its "bookkeeping file" to ascertain which source programs, if 
any, need to be recompiled. A list is printed out and the individual 
programmers are notified. They need only recompile without concern- 
ing themselves as to precisely what call store changes have been made. 

It was mentioned that PROCESS III has a powerful macro facility. 
In this context, a macro is defined to be a fixed amount of code, in some 
language, that will result in a variable amount of object program when 
it is properly "called." Just as basic instructions have variable fields 
(e.g., address, index, masking), 2 so do macros; in the case of macros, the 
variable fields are called "parameters." Since calls occur in the source 
program, the names of the macros, or more simply the macros, are said 
to be part of the source language. If one is given the ability to define 
his own macros he may thereby extend the source language. A set of 
macros which has been incorporated permanently into PROCESS III 
constitutes just such an extension. These permanent macros are saved 
as a special part of the Compool so that they may be refined and ex- 
tended still further as more is learned about telephone data processing 
functions. In addition, individual programmers may define and call 
their own macros. 

The balance of this paper is devoted primarily to three things: 
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(1) an explanation of how call store configurations are defined, 

(2) a description of the source language and some of its extensions, 
and 

(3) a discussion of the tools available to construct extensions to the 
source language. 

II. STORAGE ALLOCATION 

The design of the compiler was influenced by the real-time and space- 
limited nature of the resulting object program on the one hand, and the 
demands of an intricate basic machine order structure on the other. An 
obvious solution to the space problem was to pack information into 
subunits smaller than the natural dimensions of the available memory 
units (37 binary bits in the program store and 23 bits in the call store). 
Thus it was desirable to provide means in the compiler for naming such 
subunits, called "items," in memory. 

The object program organization 3 itself demanded of the compiler the 
ability to define several types of homogeneous blocks of temporary 
memory, each composed of several basic memory units. A group of call 
registers 34 is essentially a group of similar blocks of memory, where each 
word within one block serves the same functions as the corresponding 
word in all the other blocks. For example, the high-order bit of the sec- 
ond word in each block may indicate whether this call register is con- 
trolling a telephone call or not. Memory blocks of this call register type 
are called "scatter tables" and are defined in PROCESS III by the 
following statement: 

(1) XX SCATABLE N1,N2 

Beginning at an address called XX, statement (1) reserves space in 
memory for Nl tables each containing N2 words. 
The statement, 

(2) YY TABLE XI, N2 

defines Nl tables each containing N2 words. Memory defined with TA- 
BLE differs from that defined with SCATABLE; all the words in any 
one of the XI tables defined with TABLE have the same function, but 
the function may vary from table to table. For example, with Nl = 2, 
the rightmost 17 bits of each word in the first table might be used to store 
the line equipment number, while the second table might consist entirely 
of trunk equipment numbers in the rightmost 15 bits. 
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It is also convenient to be able to define one continuous block of stor- 
age. The compiler accepts statements like : 

(3) ZZ BLOCK N 

This reserves N words of space in memory and names the address of the 
first word ZZ. 

In order to refer to memory items smaller than the basic word by name, 
one must be able to define them. The statements below serve this pur- 
pose: 

(4) YY TABLE 10,50 

(5) YYO LAYOUT ABB--- CCCCCCCC 

(6) IT1 ITEM A 

(7) IT2 ITEM B 

(8) IT3 ITEM C 

Statement (5) lays out all 50 words of the first table in the set of 10 
tables defined by (4) in the call store area. The high-order bit is defined 
as one item, the next 2 bits as a second item, the dashes indicate bits not 
being defined, and the rightmost 8 bits constitute a third item. State- 
ments (6), (7), and (8) assign names to the three items. 
ThusITl is the name assigned to the item indicated by A in the LAYOUT 
statement, IT2 is the name of the B item, and IT3 the name of the C item. 
In a similar way items may be defined for SCATABLE and BLOCK. 

The following characteristics of items are useful in manipulating them, 
as will become obvious in the following sections. 

A.ITEM = the address of the item 

M.ITEM = the mask of the item; i.e., a 23-bit constant with all ones 

in the position of the item and zeroes elsewhere 
D.ITEM = the displacement of the item from the right 
S.ITEM = the size of the item; i.e., the number of bits contained in 

the item. 

The qualifiers A., M., D., and S. are prefixed to the name of the item to 
refer to these characteristics. For example, the items defined in state- 
ments (6), (7), and (8) have the following characteristics: 

A.IT1 = A.IT2 = A.IT3 = address named YYO 
M.IT1 = O.20000000* 



* PROCESS III assumes integers to be decimal unless qualified by O. to indicate 
thej' are octal. 
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III. SOURCE LANGUAGE 

3.1 Basic Orders 

Some of the storage allocation or storage defining facilities of PROC- 
ESS III were tailored for use by the No. 1 ESS basic orders. Since the 
nature and aims of the basic order structure have been discussed in 
some detail in an earlier article, 2 only some of their pertinent character- 
istics in connection with the use of item qualifiers are illustrated here. 

(9) MK YY0 

This instruction moves the 23-bit contents of the word named YY0 into 
the K register. The following instruction ( 10) does exactly the same 
thing: 

(10) MK A.IT1 

The triplet below [instruction (11)] sets the logic register to the mask of 
IT2, moves the contents of the item IT2 into the K register, masking 
out everything but the item by logical product (PL), and then right 
adjusts it in the K register by using the displacement of the item. 

(11) 



WL 


M.IT2 


MK 


A.IT2„PL 


HC 


D.IT2 



The same actions are accomplished in a different way by the next three 
instructions: 

(12) WX A.IT2 

MK M.IT2,X,PS 

HC D.IT2 

Because of the PS option the mask is set up and used in the same order. 
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Given a source program input such as the basic order instructions in 
(9), (10), (11), or (12), PROCESS III will produce an object program 
as output with the property that for each input instruction there will be 
exactly one output instruction. This one-to-one correspondence between 
input source program instructions and output object program instruc- 
tions defines an assembling process. On the other hand, a compiling 
process is defined to be a one-to-many correspondence between input 
source program "instructions" and output object program instructions. 
For a compiler the input "instructions" are called "statements," and the 
set of all statements meaningful to the compiler is called a "language." 
PROCESS III will accept as inputs basic order instructions and state- 
ments of its own language, called PROCESS, in any mixture.* The source 
language of No. 1 ESS programs, therefore, is nominally PROCESS plus 
the basic order instructions. It will be shown that the PROCESS lan- 
guage can be extended. 

3.2 PROCESS Language 

The basic goal of the PROCESS language is to provide the No. 1 ESS 
programmer with a means to write his source programs quickly and 
efficiently. As with any higher-level programming language, a program 
written in PROCESS cannot be better in terms of object program length 
than the same program written with basic orders by an expert program- 
mer. When used properly, however, the PROCESS language gives object 
programs that are no worse than the great majority of those written 
with basic orders by average programmers. 

The PROCESS language is intended to provide the fundamental 
programming tools needed to write telephone programs. The functions 
required in any program, including telephone programs, can be classified 
into three categories: 

( 1 ) moving data from one place to another, 

(2) making decisions using these data, and 

(3) performing arithmetic or logic operations on these data. 

While these requirements were predetermined, there were some addi- 
tional telephone-oriented programming problems that evolved as the 
programming effort got under way. These problems were solved readily 
because of the flexible macro facility of PROCESS III and the resulting 
ease in extending the source language by defining new procedures. 

Essentially, the PROCESS language consists of a set of procedures 
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that can be called by the programmer with varying input information, 
called "parameters." A description of the allowable parameters and pro- 
cedures follows. 

The nature of parameters may be discussed on two levels : 
(i) On the lower level, parameters can assume the identity of any of 
the basic units of data handled by the basic orders. The various possi- 
bilities are: 

(a) full memory words, indexed or not 

(b) items or partial words, indexed or not 

(c) constants 

(d) central control registers. 

For (a) and (b), indexing is specified by enclosing the address and index 
in parentheses, as (address, index). 

(ii) Parameters can also assume a more general nature that enables a 
programmer to nest procedures. In this case a parameter can be repre- 
sented by: 

OP(a x> Oa, ■•• ,a n ) 

Here the operator OP of the parameter can be any of the basic procedures 
of the language or the character C ; the use of C indicates that the body 
of the parameter ( • • • ) should be complemented. Each a, again can be 
of the form OP (61 , ■ • • ,b m ) or one of the forms denned by (a) through 
(d) above. 
The general-purpose procedures of the PROCESS language are: 

1. Data moving 

MOVE OP(x),b,c,d,- •• 

Function: Move the quantity specified by x to the destinations desig- 
nated by /;, c, d, and so on. If OP is a basic procedure, perforin this 
operation on x before moving the result to b and c, etc. 

2. Decision making 

(a) IF OP(.r),(r! , r 2 , ■ • ),OP(6),(<*i , d 2 , • • •) 

Function: If the quantity x or the result of the operation (if any) per- 
formed on x has the relation /-, to b or to the result of the operation (if 
a-ny) performed on b, then control is transferred to a program location 
named d { (i = 1,2,3). The allowable relations r, and their meanings are: 

E = arithmetically equal 
NE = arithmetically not equal 
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LE = arithmetically less than or equal to 
GE = arithmetically greater than or equal to 
L = arithmetically less than 
G = arithmetically greater than 
XE = logically equal 
XU = logically unequal. 

0>) COMP OP(.r),r,(&i , 6 2 , ■■■ ,!>,,), 

(4 , <h , ■ ■ ■ , d„) 

Function: If the quantity x or the result of the operation performed on 
x has the relation r to b,-, program control is transferred to r/, (i = 1, 2, 
■••,«). 

(c) IFOR OP(x),rXbi,b 2i ■■■b, l ),d 

Function: If the quantity x or the result of the operation performed on 
x has the relation r to any one of quantities 6, (i = 1, • • • , ??), program 
control is transferred to d. 

(d) IF xjrJb t OPi(cd,-~,OPuW, 

ELSE(OP^.i(c B+ 0,-",OP m (c w )) 

Function: If x has the relation r to the quantity b, then perform the 
procedures OPi , • • • , OP„ ; if not, then do OP n+1 , ■ ■ • , OP,„ . 

(e) IF x,rJb,OP l (ed,-~,OPnW, 

ALSO(OP„+i(c B+1 ),- • -.OP,,,^,,,)) 

Function: If x has the relation r to the quantity b then perform the 
procedures OPi , • • ■ , OP„ ; in any case then do the procedures OP„ + i , 
• • , OP m . 
3. Arithmetic and logic procedures 



(a) 


SUM 


OP(*),OPfo)M 


(b) 


DIFF 


OP(*),OP(y)M 


(c) 


AND 


OP(x),OP(y),b,c, 


(d) 


OR 


OF(x),OP(y),b,c, 


(e) 


EXOR 


OP(x),OP(y),b,c, 



Function: Perform the indicated operation on the parameters x and y 
after executing the function of the operators on x and y, if any, and put 
the result into b, c, etc. 
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4. Loop control 
m LOOP 



i,f,c,v 



m 



ENDLOOP 



Function: These two .statements control a loop that begins with the 
call of LOOP and ends with the call of EXDLOOP which specifies the 
same m ( name ) in the location field, i and /are the initial and final values 
of the loop variable. At the end of each pass through the loop, the loop 
variable is incremented by c. When this new value exceeds /, control 
passes to the next instruction outside the loop; otherwise control is trans- 
ferred to the beginning of the loop, v specifies the loop variable to be used. 
If v is not specified, the central control register Z will be used as a loop 
variable. It is possible to nest loops within loops. If the same loop vari- 
able is specified for more than one loop, the value of that variable is 
saved and reset when entering and leaving another loop. 

5. Initialization facility 



INIT 



b,c, 



Function : Place c and any following parameters into consecutive loca- 
tions starting with the location specified by b. 
(i. Unconditional transfer of program control 



GO*TO 



OP(ar),(6i,& 2 , ■■ ,b„) 



Function: At execution time, x or the result of the operation performed 
on x, if any, specifies a number i, and program control is transferred to 
bi . If bi is not specified, program control is transferred to .r. 

Some typical calls for these procedures are: 



START 


LOOP 


1,10,1 




MOVE 


(ITEM,X),FULL 




IF 


(ITEM,Y),E,0,DEST 




IF 


(0,Y),E,L,MOVE(0,(0,Y)), 

ELSE(MOVE(L,(0,Y))) 


DEST 


SUM 


SUM(1,(ITEM,X)),K,(0,Z) 


START 


ENDLOOP 






GO*TO 


SUM(Y,(ITEM,Z)),(D1,D2 
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The procedures described constitute the initial general-purpose sub- 
set of the PROCESS language. A realistic example showing the use of 
many of these procedures is given in Appendix A.l. 

As the needs of the No. 1 ESS program became clearer, special tele- 
phone-oriented procedures were added to this initial set to extend the 
source language. For instance there are procedures to implement a 
change in network (CIN), a change in peripheral circuit configuration 
(CIC) or signal distributor (SD) actions. These procedures have en- 
abled the programmer to implement such functions in a higher-level 
and more descriptive language, thereby relieving him of details in- 
volved in writing source programs at the basic order level. 

Procedures in the PROCESS language are in fact macro calls. The 
corresponding macro definitions for the language are retained by the 
compiler in its Compool. To extend the source language, one defines 
new macros. The extensions may be global or local. Global extensions 
to the source language are macros that have proven to be of widespread 
use among the programmers; these are entered into the Compool and 
become part of the PROCESS language, capable of being used there- 
after by all programmers. Local extensions to the language are macros 
that are defined and called by individual programmers in their own 
programs. Obviously, there may be many different kinds of local exten- 
sions to the source language. Extensions, whether global or local, are 
constructed using special macro orders in the macro definitions. 

IV. MACRO DEFINITIONS 

Each macro definition is associated with a definite name (or set of 
names) called a "macro name." When the compiler encounters a macro 
name in the operation field of the source program it looks for the defini- 
tion associated with that name. The compiler then executes the orders 
in the macro definition, which results generally in No. 1 ESS code be- 
ing generated. This code varies, depending on the parameters of the 
macro call. 

A macro definition has the form: 

DEFIN opi dumi , dum 2 , • • • , dum„ 

ordei'i 
order 2 

order* 



process in 2469 

ENDEF 

EQUAL opi op 2 , op 3 , • • • , op„ 

opi , op 2 , op 3 , • • • , op„ are all names of this definition, dunii , dum 2 , 
• • • ,dum„ arc dummy parameters. The body of the definition consists of 
the series of orders: orderi , order 2 , • • • , order* . These orders are of 
four types: No. 1 ESS instructions, macro calls, macro orders, and pseudo 
operations. The macro orders are a special subset of the PROCESS 
language useful mainly in writing macro definitions. They instruct the 
compiler to take certain actions during compile time. To help distinguish 
macro orders from other types of orders, the symbol * is the first char- 
acter of each macro order name. The meaning and syntax of the four 
order types are discussed more fully in this and succeeding sections. 

The actual notation used by programmers in writing macro definitions 
is limited by available keypunch symbols, which leads to awkward nota- 
tion in some cases ; for these cases a notation more suitable for exposition 
is used here. As previously, the remainder of this section uses small letters 
for variables, whereas capitals and special symbols such as $ are used 
literally. A detailed example of a macro definition, a macro call, and the 
operation of the compiler in expanding the definition is given in Appen- 
dix A.2. 

4.1 Parameter References 

Depending on the exact nature of a macro call, different codes are 
generated by its macro definition. In order to express this dependence 
of the code to be generated on the various parts of the macro call, a 
general scheme for referring to these parts is needed. The form of a 
macro call is: 

loc op Pt i Pa t - - - i Vn 

A call is composed of a location (also called p ), an operation (also 
called pi) and a series of parameters. Syntactically, the location and 
operation are strings of six or fewer alphanumerics. The parameters, on 
the other hand, may have some internal structure. A parameter p, is 
either a string of alphanumerics (including the null string) or it has the 
form o 8 (ps,i ,p s ,2 , • • • ,V*.n s ) in which s is an ordered set of (position) 
integers, and o B is any string of alphanumerics. An o s is called the operator 
of parameter p a . p 8 with o„ removed is called the body of p„ . The strip 
of p s is the body of p, with the outside parenthesis removed. The re- 
mainder of p„ is defined only for s = 2, 3, • • • , n. The remainder of p, 
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is p„ , p„ + i , • • ■ , p„ . The location, operation, and the parameter parts, 
operator, body, strip, and remainder of any p s may all he referred to 
directly within a PROCESS III macro definition. 

There are two methods to refer to parameters and parameter parts. 
The first method is by using "parameter indices." There are six "parame- 
ter indices" named 10, • • • ,15 for use in writing macro definitions. A 
parameter index may be set to any parameter by the macro order *SET. 
For example : 

*SET x,l0,s 

This order sets parameter index 10 to parameter p 8 if it exists; otherwise 
control jumps forward to location x in the macro definition. There is a 
companion macro order *ADV. For example: 

*ADV x,I0,t 

Assuming t is an integer and 10 is originally set to p, , where s = Si ,j, 
then this order will set 10 to p ai .u+» if such a parameter exists, and con- 
trol passes to the next order; otherwise control jumps forward to loca- 
tion x in the macro. For example, if 10 is set to p 2 .i and t = 1, then 
after a successful *ADV, 10 is set to p 2 .2 . 

One may refer to the parameter part to which a parameter index is 
set as follows: assume \j is set to p„ 

"*0""lj" refers to the operator of p a . 

"Ij" refers to the body of p„ 
"*S""Ij" refers to the strip of p., 
u *R""Ij" refers to the remainder of p a . 

The second method allows one to refer to parameters pi ,Pi, ••• p„ 
and their respective parts directly by referring to the dummy parameters 
written on the DEFIN statement. The DEFIN statement has the form: 

DEFIN op dunio, ■ • • dum„ • • • ,dum„ 

dum> may be any string of six or fewer alphanumerics. In writing the 
macro definition following a DEFIN statement, one may refer to 
parameters and their parts as follows: 

"LOC" refers to p 
"ZOP" refers to rh 
"*0""dum/' refers to the operator of p, 
"dum/' refers to the body of p. 
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"*S""dum/' refers to the strip of pj 
"*R""dum/' refers to the remainder of p> . 

If by using an expression available for referring to parameters one 
refers to a parameter that does not exist, then that expression refers 
to the symbols MSP (missing parameter). 

All the above ways of referring to parameters are called parameter 
references (pr). Parameter references can be concatenated with each 
other and can be concatenated with alphanumerics. (Alphanumerics 
exclude special symbols.) 

f A concatenated parameter reference (cpr) is defined to be of the 
form : 

x or (pr) or (cpr)(cpr)* 

in which x is any string of alphanumerics. 

f A (pr) refers to a parameter. A string of alphanumerics x refers to x. 
A concatenation of x'a and (pr)'s refers to the concatenation of the sym- 
bols to which the .r's and (pr)'s refer (referents). Generally, the con- 
catenation of any set of expressions refers to the concatenation of the 
referents of the individual expressions. 

4.2 Numerical Indexing 

There are three "numerical indices," M0,M1,M2, available for use 
in writing macro definitions. These indices refer to numbers. A numerical 
index may be set to a number with the macro order *SFI. For example: 

*SFI x,MO,ni f n, 

This sets index MO to ii\ with a limit of n> , where both in and /i 2 are 
positive integers. If n> < n t , the index will not be set and a jump forward 
to x will be executed. There is an associated macro order *AFI. It is 
written : 

*AFI x,M0,n 

If MO is set to j when this order is encountered, then MO will be set to 
j -f- n provided j + // docs not exceed the limit established on the last 
♦SFI order that referred to MO, and control jumps back to location x 
in the macro; otherwise control passes to the next order. 

* This recursive definition states that an x or a (pr) is a(cpr) and that any 
concatenation of (cpr)'s is also a (cpr). 

f This and any paragraphs similarly marked may he omit ted without loss in con- 
tinuity by those not interested in the detailed syntax of macro definitions. 
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One may refer to the number to which a numerical index Mj refers 
by the expression "Mj". 

t (cnr) is defined to be a concatenation of numerical index references. 
A (cmr) is denned to be of the form : 

(cnr) or (cpr) or (cmr) (cmr) 

(cmr) in itself is not significant; it is used as a convenience in a definition 
given below. 

4.3 Naming Symbol Strings and Parts of Symbol Strings 

A string of alphanumerics may be named and later referred to by this 
name. Also, space must be allocated to hold the strings to which the 
name refers. One method of naming strings and at the same time allocat- 
ing space is accomplished outside all macro definitions with the NAME 
statement : 

NAME nam siz,strg 

nam is the name of the string, siz is the maximum-length string to which 
this name refers, and strg is an initial string of symbols to which nam 
refers. The name of a string is limited to six characters. 

A method of renaming strings is with the macro order *ST. For ex- 
ample, 

*ST s,p 

gives the string s the name p previously assigned by a NAME state- 
ment. Later the string s may be referred to by writing [p\. 

t A string reference (sr) is defined to be of the form [(nr)] in which 
(nr) is defined to be of the form : 

(cmr) or (sr) or (cmr)(sr) or (sr)(cmr) 

An (sr) of form [(nr)] refers to the string whose name is the referent of 
(nr) as defined by using the NAME or *ST statements. If the referent 
of (nr) is not such a name, then [(nr)] refers to UN (undefined name). 

4.4 Special Functions 

Since it is expected that the parameters of a macro call will in many 
instances be the names of temporary storage elements such as items, 
registers, full words, and so on, means are provided for referring to 
properties of storage elements. These properties are: 

(1) Type: [T.(nr)] refers to different characters, depending on what 
(nr) refers to. 
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If (nr) refers to: 


[T.(r 


ir)] refers to : 


an item 

a full word 

a number 

a register item 

a register 

none of the above 


S 
F 

w 

P 

R 

UN 



(2) Item properties: if (nr) refers to an item, then [S.(nr)], [D.(nr)], 
[M.(nr)], refer respectively to the size, displacement and mask of this 
item. If (nr) is not an item all three expressions refer to UN. 

4.5 Reference Expressions 

f A reference expression is a basic element in writing macro definitions. 
Recalling the various allowable bracketed expressions (i.e., [(nr)], 
[T.(nr>], [S.(nr>], [D.(nr)], [M.(nr)]), let (csr) be any concatenation of 
these, or null. A reference expression (r) is defined as any concatenation 
of (nr)'s and (csr)'s. (r) is of the form: 

(nr) or (csr) or (r)(r) 

t A legitimate reference expression always refers to some string of 
symbols. The interpretation of this string of symbols in turn depends 
on its position within the macro string. 

4.6 Conditional 

It has been shown how one can refer to parameters and various func- 
tions of parameters. Any such reference has been called a "reference 
expression," and has been symbolized by (r). The problem now is to 
produce code that depends upon these parameter functions. To do this 
some way of specifying decisions is required. The conditional is provided 
for this purpose. 

One of the forms of the conditional is: 

Sc» 3i , q> ,ni, n 2 $ 

Syntactically, c, qi , q* , »i , n 2 are all of the form (r). A legitimate c re- 
fers to the letters C, E, G, or L and indicates the type of comparison to 
be made, qi and q-i refer either to strings of symbols or numbers that are 
to be compared depending on the interpretation of c. n x and n 2 refer to 
numbers that indicate how many characters following the conditional 
(after the second $) are to be omitted: ?h characters if the condition is 
met, n 2 characters if the condition is not met. For the condition indicated 
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by the letter C, the compiler compares the two strings referred to by 
</i and q-i for identity. For the conditions indicated by the letters E, G, and 
L the compiler compares the two numbers referred to by q x and q 2 to 
determine if q\ is respectively equal to, greater than, or less than q 2 . 
Another conditional is of the form: 

$X, v, ni , n,$ 

Syntactically, Wi and n-i are (r)'s, but p must be a parameter reference 
(pr). The interpretation of this conditional by the compiler is: if the 
parameter referred to by p exists, omit the next rt\ characters; if not, 
omit the next n-> characters (after the second $). 
Finally there is: 

$U,nS 

which means "omit the next n characters." n is of the form (r). 

In general, conditionals may be concatenated with each other and with 
reference expressions. 

4.7 Form of Orders Used in Writing Macros 

A macro definition is composed of a series of orders. The form of 
these orders is : 

loc opi pi , p 3 , • ■ ■ , p n 

or 

loC * Op 2 , P-2 , pi , • ■ ■ , Pn 

loc is an (r) consisting of six or fewer characters; op x is any concatena- 
tion of <r)'s and conditionals totaling six or fewer characters in length. 
Since six characters do not allow many <r)'s or conditionals for opi , the 
second form is available, in which op 2 is the same as op x except there is 
no limit on its length. A parameter p is either a concatenation of (r)'s 
and conditionals or of the form op(p,p, ■ ■ ■ ,p). 

Thus an order used in a macro consists of conditionals which must be 
performed, reference expressions which must be interpreted, and opera- 
tions which must be performed. The compiler does these things in the 
following fixed sequence. 

( 1 ) The conditionals are performed in sequence from left to right. A 
conditional is performed by : 

(a) first interpreting all (r)'s in the conditional (substituting referents 
for references) and then, 



process in 2475 

(b) certain parts of the order are omitted, depending upon the kind 
of conditional and substituted referents. 

(2) All (r)'s in that part of the order which remains are now inter- 
preted. 

(3) The resulting order (called an interpreted order) is performed. 
The resulting order is one of four types: 

(a) an ESS instruction in the format required of such an instruction. 
If the compiler arrives at one of these in a macro definition, the ESS 
instruction is made part of the compiled object program. 

( b ) a macro call of the form described in Section 4.1. If the compiler 
arrives at one of these it transfers control to the definition of this macro 
and begins executing the orders in that definition. 

(c) a macro order. Some of these already have been described, 
namely, *SET, *ADY, *ST, *SFI, and *AFI. The remainder of the 
macro orders are described below. 

( d ) a pseudo operation. The compiler executes the pseudo operation 
just as though it had been part of the input source program (see Section 
5.1). 

4.8 Additional Macro Orders 

The remaining macro orders are all jumps or skips of one sort or 
another. Let x be any string of six or fewer alphanumerics, n a number. 

Kb 

means jump ( , . ) to the location x. 

*JF OUT 

means jump out of this macro definition. 

-GO - 

, . /for\vard\ , 

mean skip ( , 1 over n orders. 

means execute the order at location x ( , , J of this execute order 
and then return to the order directly after this execute order. 
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In the case of the execute order, the location x must be in the same 
definition as the execute order. In the case of the jump or skip orders the 
transfer of control can be outside the macro in which the jump or skip 
occurs. 

A jump forward to location x in the definition of a macro called MAC 
causes the compiler to look for x in MAC, forward of the *JF order. If 
X is not found in MAC, the compiler continues to look forward of where 
the call for MAC occurred. This process continues until the x is found 
or the end of the input program is reached. A jump back, *JB, is executed 
similarly, except that if PROCESS III gets back to the input source 
program without having found an x, it will not look any further; the 
compiler will then process the next order in the source program. The 
skip macro orders follow corresponding rules. A detailed example of 
how the compiler handles a macro call is given in Appendix A.2. 

V. SOME RELATED DETAILS 

There are many features of PROCESS III that have been omitted 
for the sake of brevity. However, a few details are mentioned below in 
an effort to complete the general facilities of the compiler. 

5.1 Pseudu Operations and Output Listing 

PROCESS III has a variety of pseudo operations. Pseudo operations 
arc orders to the compiler that cause it either to generate data or to take 
some special action. Many of the special actions have to do with print 
control of the output listing. Two typical pseudo operations are : 

OCT 1000007777777 

SPACE 2 

The first generates 37 bits of data consisting of the octal number shown ; 
the second causes two blank lines to be "printed" on the output listing. 
The output listing of the compiler is part of the documentation of the 
No. 1 ESS program. The listing contains the symbolic source program 
as written by the programmer, and also an octal representation of the 
object program. An example is shown in the Appendix, Section A. 3. 

5.2 Machine Restrictions 

An interesting feature of PROCESS III is its ability to check for 
(and sometimes correct) certain violations in the source program. In 
addition to the usual checking performed by an assembler (e.g., unde- 
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fined and multidefhied symbols), PROCESS III checks for illegal se- 
quences of basic order instructions. These sequences, usually couplets or 
triplets, are illegal because of timing restrictions of the No. 1 ESS 
central control. The compiler either flags the violations or inserts EE 
(no operation) instructions to correct the sequence. 

5.3 Input and Correction Features 

The input to PROCESS III may be either tape or cards; in the case 
of cards, two formats are available, symbolic or crunched. Symbolic 
card input means that there is a single basic instruction or order or pro- 
cedure or pseudo operation per physical card; crunched card input is 
simply a compressed version of the symbolic information, so that more 
than one instruction is introduced per physical card. With crunched 
input every instruction in the source program is assigned a sequence 
number. These sequence numbers may be used by the programmer to 
modify his source program conveniently when he needs to recompile. 

VI. SUMMARY AND CONCLUSION 

A description of PROCESS III, a compiler-assembler for No. 1 ESS, 
has been given. The emphasis has been on the factors influencing the 
design of the compiler, the built-in PROCESS language and the facili- 
ties available for extending the source language. 

The approach used in the design of the compiler has proved very 
useful, primarily because of the flexibility it has provided. Outstanding 
among the merits of this approach is the fact that there now exist several 
telephone-oriented procedures in a language understandable to pro- 
grammers. This is not to say, however, that PROCESS III is the final 
answer to a "telephone language." The authors feel that it is accurate 
to say that PROCESS III has laid a solid foundation for a future 
PROCESS n. 
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APPENDIX 

A.l Realistic Exam-pie of a Telephone Function and Its Program 3 A 

The example shown in Fig. 1 is a realistic subprogram taken from the 
coin charge sequence of No. 1 ESS. It shows the application of the gen- 
eral-purpose procedures in programming telephone functions. It also 
demonstrates the usefulness of programmer-defined procedures such as 
LINK, which links two call registers, and SZREG A, which generates 
a program to hunt and reserve an idle call register spccilied by A. The 
accompanying flow chart (see Fig. 2) shows the close correspondence 
between the procedures of the PROCESS language and the telephone 
functions depicted on the sequence chart. 

A.2 Detailed Example of Macro Definition and Macro Call 
Definition of a macro named MV: 
DEFIN 



XYZ 



MV 


A,B,C 


Order 


♦SET 


OUT,I0,2 


1 


MK 


"*S" "A" 


2 


*ADV 


OUT,I0,l 


3 


*SF 


$C,[T."I0"],R,0,2$2,0 


4 


KM 


"*S" "10" 


5 


*JB 


XYZ 


('» 


W"I0" 


0,K 


7 


*JB 


XYZ 


8 



ENDEF 

Purpose: to move the contents of A to B to C, • • • . A may be an 
indexed or unindexcd memory location. B may be an indexed or unin- 
dexed memory location or a register. Example: assume the macro call is 

MV JACK,X,(JILL,Y) 

where JACK and JILL are call store locations and X and Y are index 
registers. 

Upon seeing this call, the compiler goes to the definition of MV. The 
steps taken by the compiler in expanding this macro call follow: 
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SAVE OR ADDRESS 
I 



CCR ADDRESS 



SET RETURN POINTER 



RETURN 
(SA) 



SAVE RETURN ADDRESS 



SEIZE CCR 



w 



(F) 



INITIALIZE CCR 



RETURN TO 
OVERFLOW 




no Xama X yes 

RECORD.,/ 



SAVE CCR ADDRESS 



NO AMAR 
AVAILABLE 



(F) / HUNT 

\ AMAR 



(ivT 



LINK OR CCR 
I 



LINK AMAR AFTER CCR 



MARK THE CALL FOR AMA 



OR -ORIGINATING REGISTER 

CCR -COIN CHARGE REGISTER 

AMA -AUTOMATIC MESSAGE 
ACCOUNTING 

AMAR -AUTOMATIC MESSAGE 

ACCOUNTING REGISTER 

(F) -FAILURE 
(S) -SUCCESS 
(SA) -SUCCESS ADDRESS 



Fig. 1 — Subprogram from coin charge .sequence. 



(1) it sets 10 to JACK; 

(2) it produces: 

MK 



JACK 



(3) it advances 10 to X; 

(4) it interprets the conditional, 

$C,[T.X],R,0,2$ 
of order 4, which results in order 4 being interpreted as 



(order 1) 

(order 2) 
(order 3) 



kSF 
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part «r caiN charge piugr 


»M 
















9 


52X2 


EXTERN 
H0VE 


0R£VF2,AMSZN0 
J, 10 




10 

11 


XX 


SJReg 
Leap 


CNC(K),0R0VF2 
l.V.S.CNC-l.ltZ 




12 

13 


XX 


M0VE 
ENDLZ0P 


DidiKAl 




K 

15 




IF 

M0VE 


IkAMA,X),NE,V.RECRD,N0AmA1 
Y,T1 




17 




G0.T3 


N0AMA1 




19 




M0VE 


IliV 




20 
21 




LINK 
LINK A 


flRlXl.CCRtV) 
AMAIZ I.CCRIY) 




23 


MAIN 


AND 


(CIYP,X1,2,Z 




2<, 
25 




IF 
M0VE 


ICZLtXl.Ef 1>0R(Z.1,Z) 

(BILL, XI, (CHIN, VI 




27 




H0VE 
M0VE 


X.T1 

v,x 




?9 




SETPT 
G0M0 


pri 
iro,«) 




31 




LINK 
G0-JO 


MAIN 




0000064 32 




END 





Fig. 2 — Flow chart for sequence of Fig. 1. 

(5) it arrives at order 7, which produces: 

WX 0,K 

(6) it returns to order 3; (order 8) 

(7) it advances 10 to ( JILL,Y) ; (order 3) 

(8) it interprets the conditional, finding that ( JILL,X) 
is not a register and skips to order 5; 

(9) it produces: 

KM JILL,Y (order 5) 

(10) it returns to order 3; (order 6) 

(11) it cannot advance 10 any further and therefore 

jumps out of the macro definition. (order 3) 

A.3 Example of an Output Listing 

Fig. 3 is a typical output listing. 

Starting on the extreme left, the interpretations of the columns are: 

(1) relocatable locations assigned to the object program 

(2) a three-character console code corresponding to the operation 
part of the instruction 

(3) the 37-bit octal representation of the instruction 

(4) sequence numbers: each statement in the source program has 
such a number 
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PART 


i!F CZ1N CHARGE PRPGRAH 

6 EXTERN 3Ri;VF2, AMSZN3 






OCOCOOCC 


7 


S2X2 

S2X2 


KCVC 
SYN 


J, TO 
X. 


0000000 


120 


000500 C015621 


B 




JH 
SZREG 


TO 
CNCIKI.0R0VF2 


0000001 
00CO0O2 


010 
010 


0400*0 0OCOCC4 
C00040 C000C01 






T 
T 


YASCNC..J 
CRCVF2 


00C0C03 


74C 


C3364 00000000 


9 


XX 


HK 

Leap 


0,Y 
l.V.S.CNC-l.l.Z 






OC000014 
O0OC0C01 




9 10 


SET 

SET 


V.S.CNC-1 
1 


0000004 


730 


00354 OC0OOCO1 

OC000005 




XX 


MZ 

SYN 


1 
X. 


O0OO0C5 


042 


120210 C0C0O01 


10 




Mevt 

EZEM 


0.(1. KA) 

l.KA 


0000006 


730 

43G 
037 


03754 OOOOOCOl 


11 


XX 


ENOL00P 
WZ 


V.9I0.Z 


00000O? 
00OO01C 


07614 000C0014 
000166 COCC005 






CMR 

TCLE 


V.9F0.Z 
XX 








12 




IF 


IRAMA,X),NE,V.RECRO,N0AMA1 



0000011 
0000012 
0000013 
0000014' 



720 00310 OCOCOOIC 



350 025642 C0C0C16 
742 04361 OCOCOOIC 



A.RAHA.X.PL 
V.V.RECR0«t.3 



7J3T 000146 C000C60 



TCAU 
MevE 



N0AMA 1 
Y, 1 1 



0000015 


130 00054C 


0015622 


14 


YM 
G0«T!" 


Tl 
(AHSZN0..J) 


0000016 


010 C40040 


0000002 


15 


G0*1 E 


NflAMAl 




010 C0CO4O 


C0C006C 


16 


T 
G0»T2 


N0AHA1 
N0AMA1 


0000020 


010 000040 


OOCOOAO 


17 


MCVE 


N0AHA1 
11. V 


0000021 


300 OOUOO 


C015622 


18 


LINK 


0R(X),CCR(Y) 


0000022 













0000023 

000002*. 



001 04C022 OOC0003 



/50 G3J64 OCOOOOOO 



EXTERN 
LINK A 



TJ7? 
C0L INK 
AMAIJl.CCRi 



0000025 
0000076 
0C00027 



202 03501C OOCOCOC 
ICO 03440 4C040COO 
720 0035C 37777777 



H.Y4CI.Z.ES 
H.Y4LINK 

A.V4lINV,y,PL 
a.y4link.y.el 




350 C31642 C0C0002 

132 03C552 COC0002 

4452 C0C0C02 



RTT 

wevE 



720 C0350 0400000C 



A.Y4LlNK,7,Er 
1 , I AHAR.Y) 
"V.l«E.20 
M.AMAR 



Fig. 3 — Typical output listing. 

(5) source and object program symbolic statements: the indented 
statements were generated by the compiler and were not part of the 
source program. 
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